Methods and apparatus for creating and storing secure customer receipts on smart cards

ABSTRACT

A system for creating, storing and retrieving secure transaction receipts. These transaction receipts may be stored on portable electronic media that can be carried by a consumer. Each transaction record contains information detailing the product or service purchased as well as a merchant ID and a customer (or other user) ID and an encrypted signature created from that data. The data can be further protected by the use of an optional user password. Examples of suitable portable storage media are personal computer diskettes, magnetic stripe cards or smart cards. The secure electronic transaction receipts may be used as substitutes for paper receipts. The portable electronic media is capable of storing a large plurality of such transaction records, thus simplifying a number of record keeping procedures, such as expense reporting and data entry for personal finance programs.

FIELD OF THE INVENTION

The present invention relates generally to improvements in the creation,storage and utilization of various types of transaction data includingbusiness, travel expense data, retail customer receipt data, and thelike. In particular, the invention relates to advantageous methods andapparatus for processing various transactions, incorporating merchantauthentication or signature data into certain individual transactions,storing these transactions securely on removable media and allowingaccess to the transactions by various entities including retailcustomers and retail merchants.

BACKGROUND OF THE INVENTION

The processing of most retail transactions is accomplished utilizingsome type of computerized system. A typical retail transaction in astore, hotel, restaurant or at an airline counter involves aPoint-of-Sale (POS) system comprised of one or more POS terminals, a POSsystem controller and other related devices. At the completion of thetypical transaction, the customer tenders payment and receives some typeof transaction confirmation, such as a paper receipt.

A typical consumer will purchase goods and services from numerousmerchants throughout a given period of time. The transaction processesfor all of these purchases are quite similar although the nature of themerchant and the purchase may vary considerably. One feature common tothese different transactions is the need for the consumer to retaintheir paper receipts for any returns they may wish to make later. Theprocedure for processing returns varies among retailers. Some retailersstill rely upon the authenticity of the paper receipt alone, but mostretain the transaction data electronically for some period of time. Thistransaction data is typically transmitted to a remote database at acompany's headquarters overnight, although some retailers utilize atrickle transmit system to send the data in near real-time. The data maybe retained in the store where it originated for a period of months, andindefinitely at the central database. When a customer presents an itemfor return to the store of original purchase, the retailer willtypically attempt to verify the validity of the receipt by finding thetransaction on the POS system. If this procedure fails, the system willlook for the transaction data in the central database. If both systemsare unavailable, the retailer may accept the paper receipt as long asthe receipt appears to be valid (i.e. proper paper stock, proper format,etc.), alternately issue a merchandise credit, or deny the returnoutright. This process can be time consuming for both the retailer andthe consumer. The retailer may be exposed to fraud when the POStransaction data is unavailable or corrupted, and the return process canresult in customer dissatisfaction. Customers are burdened with the needto retain paper receipts in good condition until they are sure that theywill not return purchases. The problem to be solved, therefore, is toeliminate the need for paper receipts by providing a secure means ofstoring and accessing the transaction data for both the retailer and thecustomer.

A related problem exists for the consumer that wants to keep track ofhis or her expenses utilizing a personal computer and an appropriatepersonal finance application program. A typical program requires theconsumer to periodically enter data manually into the personal computerto ensure that the expenses are properly recorded and categorized.Unfortunately, the information provided by a paper receipt is ofteninadequate for properly entering this information. Depending on themerchant, the printed receipt may use highly abbreviated descriptionsdue to the constraints of the paper stock and receipt printer. Also, theproblem is compounded when a consumer shops in a multiple-format store.For example, a single physical store location may sell groceries as wellas hardgoods and clothing. This requires the consumer to understand theprinted description well enough to know which category an individualpurchase item should be assigned to. The problem to be solved therefore,is to be able to minimize the amount of manual data entry andinterpretation required to efficiently use a personal finance program.

A related problem involves the processing steps required to trackbusiness travel expenses, and the steps required to submit travelexpense accounts to an employer. For example, in the course of even abrief trip, a business traveler may pay for an airline ticket at aticket counter, a magazine at a kiosk, a rental car at a rental counter,a meal in a restaurant and check into a hotel for overnight lodging. Atthe end of the trip, the traveler may have accumulated a significantnumber of paper receipts in various formats. These receipts must then besubmitted to the company's expense accounting department forreimbursement of those expenses that are valid business expenses. Thetraveler usually bears the burden of keeping track of those receiptsduring the trip. He must then sort and copy those receipts related tobusiness expenses, and then submit them with an expense account form forreimbursement. The expense accounting department must then review theexpense account form and the receipts for accuracy before processing thetraveler's reimbursement. This largely manual process is tedious andtime consuming for both the traveler and the expense accountingdepartment. The problem to be solved, therefore, is to provide a meansof automating this manual process and to increase the accuracy of theresulting reimbursement.

There exists, then, a need in a wide variety of contexts for a systemthat allows for the creation and storage of secure transaction data.Such a system should allow individuals to consolidate transaction datafrom various sources into a single portable, secure medium. The systemshould also allow merchants to create the transaction records theydesire, and to store such records by a secure means. The portable mediumneeds to be able to accept data from various merchants with some meansof authentication, while providing the media holder with an acceptabledata security.

SUMMARY OF THE INVENTION

A transaction data system according to one aspect of the presentinvention preferably includes a mechanism for a merchant to writetransaction data to a portable medium such as a magnetic stripe or asmart card. The transaction data includes information that describes thepurchased goods and services as well as information that identifies themerchant and the consumer. The sum of these elements comprises acomplete record of an individual retail transaction. The transactiondata is preferably authenticated by including a unique signature foreach complete transaction sequence. The signature is generated byencrypting the various elements of transaction data from an individualretail transaction. The resulting record of the transaction data is alsowritten to the merchant's POS system or other transaction system. Theportable medium is carried by the consumer and can be read by a suitabledevice attached to a merchant's POS system, as well as a similar deviceattached to a personal computer. The holder of the medium may secure thestored data to prevent unauthorized users from reading such data byassigning password protection to all data stored on the medium, or toindividual transactions.

The following Detailed Description and accompanying drawings willprovide a more complete understanding of the present invention as wellas describing further features and advantages of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a POS terminal including a smart card reader/writerfor use with the present invention;

FIG. 2 illustrates a POS store system for implementing one embodiment ofthe present invention;

FIG. 3 illustrates a flow chart of a merchandise return procedure inaccordance with the present invention;

FIG. 3a illustrates an alternative merchandise return procedure inaccordance with another embodiment of the present invention;

FIG. 4 illustrates a flow chart of a business expense accountingprocedure in accordance with the present invention;

FIG. 5 illustrates a procedure for importing and parsing consumer datain accordance with the present invention;

FIG. 6 illustrates a detailed transaction record in accordance with oneaspect of the present invention;

FIGS. 7a and 7 b illustrate the interchange of data between a merchantsecure medium, a customer secure medium and a POS terminal in accordancewith the present invention;

FIG. 8 illustrates a method for generating a merchant signature inaccordance with the present invention;

FIG. 8a illustrates an alternate method for generating a merchantsignature in accordance with the present invention; FIG. 9 illustrates amethod for generating an optional customer signature in accordance withthe present invention;

FIG. 10 illustrates a method for verifying a merchant signature storedon a customer secure medium in accordance with the present invention;and

FIG. 11 illustrates a method for verifying a customer signature storedby a merchant on a POS database in accordance with one embodiment of thepresent invention.

DETAILED DESCRIPTION

The present invention provides a system for generating authenticatedelectronic retail transaction receipts and storing them on a secure,portable medium. A retail transaction receipt, or record, may besuitably comprised of, but is not limited to, certain data elements suchas the time and date of the transaction, the price and description ofthe items or services purchased, a retail merchant identifier, acustomer identifier and a merchant signature.

FIG. 1 illustrates a typical POS terminal 100 adapted for use inconjunction with the present invention as described further below. Abase unit 110 includes a microprocessor 111, memory 112 and acommunications adapter 113. The POS terminal 100 communicates with othercomputers via the communications adapter 113 via a local area networkconnection 150. Peripheral input and output devices are connected to thebase unit 110 including an operator keyboard 121, an operator display123, a cash drawer 120, and a receipt printer 122 for printing paperreceipts. A magnetic stripe card reader 124 may also be connected forcredit card transactions. A PIN pad 125 may also be attached to allow aconsumer to enter a Personal Identification Number (PIN) authorizingdata to be read from a magnetic stripe card or a smart card 131. The PINpad 125 may be alternately used to allow a consumer to enter a PersonalIdentification Number (PIN) for use in conjunction with debit cardtransactions. A smart card reader/writer 130 is optionally attached tothe base unit in an embodiment of the invention that uses a smart card131 as the portable medium.

The POS terminal 100 is adapted for use in conjunction with the presentinvention by storing software in the memory 112 of the POS terminal thatperforms the routine required to generate the detailed transactionrecord illustrated in FIG. 6 and described further below.

FIG. 2 illustrates a POS system 200, including one or more POS terminals210 and one or more store controllers 220 that provide price data to thePOS terminals 210 and retain a local database 221 of past transactions.The system optionally includes an in-store processor (ISP) 230, aseparate computer dedicated to managing a communications link 231 with acentral database facility 232 as well as performing other storeoperations. The POS terminals 210, the store controllers 220 and thein-store processor 230 each have communications adapters such as thecommunications adapter 113 in FIG. 1 and are connected via a local areanetwork 240.

FIG. 3 illustrates a procedure 300 for processing returned merchandise.At process step 302, a customer presents merchandise to a store clerk ata POS terminal such as the POS terminal 100 in FIG. 1. The store clerkinitiates a return query on the POS system and is prompted by theapplication software at step 304 to insert the merchant smart card intoa smart card reader/writer. Alternatively, the merchant smart card datacan reside in the POS system software obviating the need for step 304.At step 306, the POS system software prompts the customer to insert hissmart card into a smart card reader/writer such as the smart cardreader/writer 130 in FIG. 1. At step 308, the POS system softwarevalidates the authenticity of the original purchase transaction bycomparing the data on the customer smart card to the corresponding datarecord on a store controller such as the store controller 220 in FIG. 2.If the transaction data record was found on the store controller at step308, step 310 allows the POS system software to proceed to step 314 andthe return is processed and a return or refund transaction receipt isgenerated for the customer. At step 320, the return or refundtransaction record is written to both the customer smart card and thestore transaction database on the store controller.

If a corresponding data record is not found on the store controller atstep 308, step 310 allows the POS system software to proceed to step312. At step 312, the POS system software queries a central databasefacility for the transaction data. This central database facility istypically remotely located as illustrated by the central databasefacility 232 in FIG. 2. At step 316, the POS system software determinesif the transaction data was found in the central database facility. Ifthe data was found, the POS system software proceeds to step 314. If thetransaction data record was not found on the central database facilityat step 316, the POS system software proceeds to step 318 to confirm theauthenticity of the data on the customer smart card. If the data on thesmart card is authenticated, the store clerk is authorized to accept thereturned merchandise and process a refund. This approach provides asubstantial improvement over a manual process that relies upon the clerkto determine if the paper receipt is valid and that often involves atime consuming approval procedure by the clerk's supervisor.

FIG. 3a illustrates a procedure 350 for processing returned merchandiseusing the data contained on a customer smart card and merchant smartcard only. At process step 352, a customer presents merchandise to astore clerk at a POS terminal such as the POS terminal 100 in FIG. 1.The store clerk initiates a return query on the POS system and isprompted by the application software at step 354 to insert the merchantsmart card into a smart card reader/writer attached to the POS terminal.In an alternate embodiment, the merchant smart card may besemi-permanently inserted in a smart card reader/writer that is notreadily accessible by the store clerk. This could be accomplished byhaving a dedicated smart card reader/writer secured in a wrap standunder the POS terminal or elsewhere in the store. In another alternateembodiment, the merchant smart card data can be an integral component ofthe POS system software. Either of these alternate embodiments wouldobviate the need for step 354. At step 356, the POS system softwareprompts the customer to insert their smart card into a smart cardreader/writer such as the smart card reader/writer 130 in FIG. 1. Atstep 358, the POS system software prompts the store clerk to validatethe identification of the customer utilizing the customer ID data on thecustomer smart card. The identification of the customer may beaccomplished in a number of ways. For example, the customer may be askedto enter a PIN number on a PIN pad, to confirm some piece of personalinformation that is stored on the smart card, or a digital photograph ofthe customer stored on the smart card can be displayed on the POSoperator display so that the customer can be visually identified. ThePOS system software then proceeds to step 360 to verify the authenticityof the relevant transaction data corresponding to the returnedmerchandise. Process step 360 attempts to reconstruct the merchantsignature utilizing the merchant key and the transaction data on thecustomer smart card. If the merchant signature does not match, theprocess proceeds to step 364 which prompts the store clerk to reject thereturned merchandise. If the merchant signature does match, the relevanttransaction data is authenticated and the system proceeds to step 362which prompts the store clerk to accept the returned merchandise. Atstep 366, the returned merchandise is removed from the transactionrecord and a revised merchant signature is generated that reflects thecurrent contents of the relevant transaction data. The customer smartcard data is also updated as is the local POS database. This approach isan improvement over a manual process that relies upon the validity ofthe paper receipt and the clerk's determination of such validity only.

FIG. 4 illustrates a process 400 whereby a business traveler or otherconsumer purchases a series of goods and services in the course of abusiness or shopping trip. At step 402, the purchaser completes atransaction that includes the use of a smart card such as the smart card131 in FIG. 1. A data record of the transaction is written to thepurchaser's smart card at step 404. If the purchaser has no morepurchases to make, step 406 causes the process to proceed to step 408.Otherwise, steps 402 and 404 repeat as more purchases are made. At theend of the trip, the consumer inserts the smart card into a smart cardreader attached to a personal computer such as the smart cardreader/writer 130 in FIG. 1. The transaction data on the smart card isread at step 408. The consumer is then prompted to provide an optionalpassword at step 410 allowing the data on the smart card to be accessed.In the example where the consumer is a business traveler, process step412 would prompt the consumer to select and verify the appropriate datatransaction records to be sent to the expense accounting department forreimbursement. In the example where the consumer is a shopper, processstep 412 would prompt the consumer to select and categorize data recordsby transaction type or other parameters. At step 414, the smart card isupdated to indicate those data records that have been read. The datarecords that have been read may alternately be deleted from the smartcard.

FIG. 5 illustrates a process 500 whereby the transaction data recordsstored on a smart card are processed by an application program runningon a personal computer. The transaction data records are read from thesmart card at step 502 by a smart card reader/writer attached to apersonal computer such as the smart card reader/writer 130 in FIG. 1.The application program may prompt the user for an optional password atstep 504 before allowing the smart card data to be imported into thepersonal computer program. At step 506, the user is prompted to confirmthat the data has been read properly before the data is manipulated bythe program. At step 507, the user is presented with a number of choicesfor manipulating the data. The program may parse and sort the data basedupon various parameters chosen by the user. Examples of such parametersare the product descriptions, the merchant ID or the merchant category(restaurant, hardware store, etc.). The program could allow the user tore-categorize the data as the user sees fit. The sorted data could thenbe exported to other computer programs, such as a personal financialprogram, for further processing.

The user is prompted at step 508 to choose whether the smart card datashould be updated by flagging those records that were read in step 506.If the user chooses to update the records on the smart card, the processproceeds to step 510 and the transaction data records are marked ashaving been read. If the user chooses to not mark the records as havingbeen read, the process prompts the user to choose whether to delete therecords from the smart card at step 512. If the user chooses to deletethe data records, the process proceeds to step 514 and deletes thetransaction data records from the smart card and the process ends. Ifthe user chooses not to delete the transaction data records, the processends.

FIG. 6 illustrates a detailed transaction data record 600. In apreferred embodiment of the invention, a detailed transaction record orreceipt is generated. A transaction record is a generic term used hereinto describe a variety of types of records of various transactions forservices or retail goods. Receipts generally refer to the papertransaction records created by the sale of goods or services in retailcommerce. The detailed transaction record 600 may suitably include, butis not limited to, a merchant ID 601, customer ID 611, the date of thetransaction 620, the time of the transaction 630, a list of the goods orservices sold 670-675, a transaction amount total 640, tender type 641,a merchant signature 650 and an optional customer signature 660. Themerchant identifier is a number unique to a specific merchant and/ormerchant location. The list of goods or services will include priceinformation and may include specific product identification informationsuch as Universal Product Code (UPC), a merchant's proprietary stockkeeping unit number (SKU), a merchant's proprietary price look-up (PLU)number, European Article Number (EAN), alphanumeric product descriptors,or the like.

The merchant ID 601 and the merchant key 602 are numbers or alphanumericdesignations that can be unique to a specific merchant or a specificmerchant location. The customer ID 611 and the customer key 612 arenumbers or alphanumeric designations that can be unique to a specificconsumer or consumer group such as employees of a specific company.

The merchant signature 650 is preferably generated by encrypting thedata contained in the transaction record and a merchant key 602. Themerchant ID 601 and merchant key 602 can be contained in the memory of amerchant's smart card 600, in the memory of a merchant's POS system,supplied by a clerk during the transaction, or some combination of theabove. For example:

Merchant Signature 650=Encrypt {(601,611,620,630,640,641),602}

The optional customer signature 660 is generated by encrypting the datacontained in the transaction record and a customer key 612. The customerID 611 and customer key 612 can be contained in the memory of acustomer's smart card 610, supplied by the customer during thetransaction via a PIN pad or other mechanism, or some combination of theabove. For example:

Customer Signature 660=Encrypt {(601,611,620,630,640,641),612}

In the preferred embodiment the generation of the merchant signature 650involves two secure media, a merchant's smart card and a customer'ssmart card. The merchant smart card contains the merchant ID 601, themerchant key 602, and the processing steps or algorithm to authenticatethe customer smart card and create the merchant signature 650. Thecustomer smart card contains the customer ID 611, the customer key 612,and the processing steps or algorithm to authenticate the merchant smartcard and create the optional customer signature 660.

In another embodiment, of the invention a second merchant signature 690is generated from the first merchant signature 650 and a key is derivedfrom the data of each transaction such as the customer ID and themerchant key. For example:

Transaction Session Key 680=Encrypt {611,602}

Merchant Signature 690={650-Encrypt (611,620,630,640,641,680)}

Symmetric encryption may be used to create merchant signature 650,customer signature 660, transaction session key 680 and second merchantsignature 690. This would allow the merchant to verify any of thesesignatures with the same keyspace. Alternately, asymmetric encryptioncould be used to create these signatures. This would allow the merchantto publish the key used to verify the signatures for use within a givenretail chain establishment or by others. For instance, a merchant couldprovide another company its key such that this other company couldverify transaction records. This approach could be useful in the systemillustrated above in FIG. 4.

FIGS. 7a and 7 b illustrate a process 700. The process 700 illustratesthe interchange of data between the merchant secure medium, the customersecure medium and the POS terminal. Both the merchant secure medium andthe customer secure medium may be smart cards. Process 700 is used toauthenticate the merchant secure medium to the customer secure medium.Additionally, this process is used to authenticate the customer securemedium to the merchant secure medium. Some of these authenticationprocesses may be optional based on the level of security desired. Theprocess begins at process step 702, when a POS terminal such as the POSterminal 100 in FIG. 1 sends a command to a customer secure medium suchas the smart card 131 in FIG. 1, beginning the receipt session. Thiscommand could contain a series of parameters that select an appropriaterandom number generator, an appropriate encryption algorithm andappropriate key for this particular receipt session. At step 704, thecustomer secure medium generates a block of customer random data andencrypts the block of customer random data with the selected key andalgorithm. Both the customer random data and the encrypted customerrandom data are stored in the customer secure medium. At step 706, thecustomer secure medium sends data to the POS terminal consisting of acommand status indicator, the customer identifier (ID), the block ofcustomer random data, and the encrypted block of customer random data.At step 708, the POS terminal checks if the data from the customersecure medium contains the expected status and that the data is in theproper format. If both the status and format are correct, the processproceeds to step 712. Otherwise, the process branches to step 710 and analert is sent to the POS terminal application indicating that thecustomer secure medium could not be authenticated. The POS terminalapplication may optionally be programmed to notify the operator that thecustomer secure medium is not loaded with the appropriate merchantapplication.

At step 712, the POS terminal sends a command to the merchant securemedium to begin a receipt session with the merchant secure medium. Theblock of customer random data and the block of encrypted customer randomdata are sent to the merchant secure medium with the command. Thiscommand could contain a series of parameters that select an appropriaterandom number generator, an appropriate encryption algorithm and anappropriate key for this particular receipt session. If a derivedsession key is desired, session specific information such as adate/time, session counter, or consumer ID could be included. At step714, the merchant secure medium encrypts the block of customer randomdata and compares it to the block of encrypted customer random data. Atstep 716 the presented block of encrypted customer random data iscompared to the computed block of encrypted customer random data. If thedata is identical the process proceeds to step 720, otherwise theprocess branches to step 718 and the merchant secure medium sends analert to the POS terminal indicating that the customer secure mediumdata was not authenticated.

At step 720, the merchant secure medium generates a block of merchantrandom data and encrypts the merchant random data. Both the merchantrandom data and the encrypted merchant random data are stored in themerchant secure medium. At step 722, the merchant secure medium sendsdata to the POS terminal consisting of a command status indicator, themerchant identifier (ID), the block of merchant random data, and theencrypted block of merchant random data. At step 724, the POS terminalchecks if the data from the merchant secure medium contains the expectedstatus and that the data is in the proper format. If both the status andformat are correct, the process proceeds to step 728. Otherwise, theprocess branches to step 726 and an alert is sent to the POS terminalapplication indicating that the customer secure medium does not containthe data required for the receipt session to continue. The POS terminalapplication may optionally be programmed to add the merchant's detailedreceipt application to the customer secure medium. At step 728, the POSterminal application program sends a command to the customer securemedium that verifies the merchant data to the customer secure medium.The block of merchant random data and the block of encrypted merchantrandom data are included with the command. This command may contain aseries of parameters that select an appropriate random number generator,an appropriate encryption algorithm and an appropriate key for thisparticular receipt session. If a derived session key is desired, sessionspecific information such as a date/time, session counter, or merchantID may be included. At step 730, the customer secure medium encrypts theblock of merchant random data. At step 732, the presented block ofencrypted merchant random data is compared to the computed block ofencrypted merchant random data. If the data is identical, the processproceeds to step 736. Otherwise, the process branches to step 734 andthe customer secure medium sends an alert to the POS terminal indicatingthat the merchant secure medium data was not authenticated. At step 736,the POS terminal application program checks if the data from thecustomer secure medium contains the expected status and that the data isin the proper format. If both the status and format are correct, theprocess proceeds to step 742. Otherwise, the process branches to step740 and an alert is sent to the POS terminal application indicating thatthe customer secure medium failed to authenticate the merchant data. ThePOS terminal application may optionally be programmed to notify theoperator that the merchant secure medium does not appear to contain thedata necessary to continue the receipt application. The operator maythen be instructed to ask the consumer if he would like to have thecustomer secure medium replaced or updated so that the merchant securemedium can be authenticated. If the process proceeds to step 742, thecustomer secure medium has been properly authenticated by the merchantsecure medium and vice versa.

FIG. 8 illustrates a process 800 for generating the merchant signatureand writing it to the customer secure medium. This process allows thecustomer secure medium to verify the authenticity of a detailedtransaction receipt to a merchant secure medium in conjunction with thepresent invention. At step 802, a POS terminal such as the POS terminal100 of FIG. 1 sends a ‘Present Transaction Data’ command to the merchantsecure medium. This command instructs the merchant secure medium to sendthe data from the current retail transaction and includes specific dataelements that are unique to a given retail transaction. These dataelements may include the merchant identifier (ID), the customer ID, thetransaction date, the transaction time, the transaction total, and thetender type. At step 804, the merchant secure medium encrypts the dataelements from the current transaction with a merchant signature key,generating the merchant signature. At step 806, the merchant securemedium sends the merchant signature to the POS terminal. At step 808,the POS terminal application program formats the detailed transactiondata record, or detailed receipt, such as the data record of FIG. 6, toinclude the merchant signature. At step 810, the POS terminal sends a‘Write Detailed Receipt’ command to the merchant secure mediuminstructing the merchant secure medium to write a signed detailedtransaction record to the customer secure medium. The ‘Write DetailedReceipt’ command includes the detailed transaction data record. Thecustomer secure medium might require additional security steps beforedata may be written. Such steps may include the requirement of passwordverification and customer key presentation before the write command maybe sent. For some secure medium, the writing of a detailed transactionrecord may require a series of individual write commands for each dataelement rather than a single command. In addition, secure messageauthentication codes may be required. At step 812, the transaction datarecord is written to the customer secure medium. The customer securemedium then sends a message to the POS terminal indicating whether thewrite operation was successful.

FIG. 8a illustrates a process 850, an alternate process for generatingthe merchant signature and writing it to the customer secure medium.This process adds a transaction key that is specific to eachtransaction. At step 852, a POS terminal such as the POS terminal 100 ofFIG. 1 sends a ‘Present Transaction Data’ command to the merchant securemedium. This command instructs the merchant secure medium to send thedata from the current retail transaction and includes specific dataelements that are unique to a given retail transaction. These dataelements may include the merchant identifier (ID), the customer ID, thetransaction date, the transaction time, the transaction total, and thetender type. At step 854, the merchant secure medium generates atransaction session key by encrypting the customer ID with the merchantsignature key. At step 856, the merchant secure medium generates themerchant signature by encrypting the data elements from the currenttransaction with the transaction session key. At step 858, the merchantsecure medium sends the merchant signature to the POS terminal. At step860, the POS terminal application program formats the detailedtransaction data record, or detailed receipt, such as the data record ofFIG. 6, to include the merchant signature. At step 862, the POS terminalsends a ‘Write Detailed Receipt’ command to the merchant secure mediuminstructing the merchant secure medium to write a signed detailedtransaction record to the customer secure medium. The ‘Write DetailedReceipt’ command includes the detailed transaction data record. Thecustomer secure medium might require additional security steps beforedata may be written. Such steps may include the requirement of passwordverification and customer key presentation before the write command maybe sent. For some secure medium, the writing of a detailed transactionrecord may require a series of individual write commands for each dataelement rather than a single command. In addition, secure messageauthentication codes may be required. At step 864, the transaction datarecord is written to the customer secure medium. The customer securemedium then sends a message to the POS terminal indicating whether thewrite operation was successful.

FIG. 9 illustrates a process 900, a process for generating an optionalcustomer signature and writing it to the customer secure medium and aPOS database. This customer signature allows a merchant to verify thevalidity of a customer retail transaction and adds an additional layerof authenticity to the related transaction data. At step 902, the POSterminal sends a ‘Request Customer Signature’ command to the customersecure medium. This command instructs the customer secure medium togenerate a customer signature and send it to the POS terminal. At step904, the customer secure medium encrypts the detailed transaction datawith a customer signature key, generating the customer signature. Thecustomer signature key may be derived utilizing a master merchant key,thus allowing signatures to be verified against an individual customer.In addition, session specific keys may be generated utilizing atransaction session key as described above in process 800. At step 906,the customer secure medium sends the customer signature to the POSterminal. At step 908, the POS terminal application program formats thedetailed transaction data record, or detailed receipt, such as the datarecord of FIG. 6, to include the customer signature. At step 910, thePOS terminal writes the detailed receipt with the imbedded customersignature to a POS database such as the local database 221 in FIG. 2.

FIG. 10 illustrates a process 1000, a process for verifying a merchantsignature stored on a customer secure medium. The process can also beused to verify a merchant signature that is stored in a POS database.This verification process is used to check the validity of a customerreceipt when a customer presents merchandise to be returned to themerchant. At step 1002, the POS terminal sends ‘Start Verification’command to the customer secure medium. This command instructs thecustomer secure medium to send the customer ID to the POS terminal,which is received at step 1004. At step 1006, a ‘Request DetailedReceipt’ command is sent to the customer secure medium. The customersecure medium responds to this command by sending the relevant detailedtransaction data receipt to the POS terminal. At step 1008, the POSterminal sends a ‘Verify Detailed Receipt’ command to the merchantsecure medium. This command instructs the merchant secure medium toverify the detailed transaction data from the secure customer medium.The merchant secure medium encrypts the transaction data with themerchant signature key at step 1010. This encryption step generates acomputed merchant signature that is then compared at step 1012 to themerchant signature from the transaction data. If the merchant signaturesdo not match, the process branches to step 1014, and the merchant securemedium sends a command to the POS terminal indicating that the receiptdata from the customer secure medium could not be verified as beingvalid. If the signatures do match, the process proceeds to step 1016,and the merchant secure medium sends a command to the POS terminalindicating that the receipt on the customer secure medium is valid.

FIG. 11 illustrates a process 1100, a process for verifying a customersignature stored by a merchant on a POS database such as the localdatabase 221 in FIG. 2. The process can also be used to verify amerchant signature that is stored in a POS database. This verificationprocess is used to check the validity of a transaction data receiptstored on a database. Utilizing this process would limit the ability ofa merchant's employee to generate fraudulent receipts in the merchant'sdatabase. The process begins at step 1102 when the POS terminal sends a‘Start Verification’ command to the merchant secure medium. At step1104, the merchant secure medium sends the merchant ID to the POSterminal. At step 1106, the POS terminal sends a ‘Verify CustomerSignature’ command and the relevant transaction data to the merchantsecure medium. At step 1108, the merchant secure medium encrypts thedetailed transaction data with the customer signature key, generating acomputer customer signature. At step 1110, the merchant secure mediumcompares the computed consumer signature with the consumer signaturefrom the database. If the customer signatures do not match, the processbranches to step 1112, and the merchant secure medium sends a command tothe POS terminal indicating that the receipt data from the databasecould not be verified as being valid. If the signatures do match, theprocess proceeds to step 1114, and the merchant secure medium sends acommand to the POS terminal indicating that customer signature from thereceipt on the database is valid.

I claim:
 1. A method for creating authenticated electronic retailtransaction receipts by generating a retail merchant's signature, themethod comprising the steps of: storing data in a computer memory, saiddata comprising a retail merchant identification number, retail customeridentification number, and transaction data; storing in a computermemory a merchant supplied signature key; encrypting said data with themerchant supplied signature key to generate a merchant signature;generating a record comprising said merchant signature and detailedtransaction data; and storing the record on a point of sale (POS)system.
 2. The method of claim 1 further comprising the step of writinga copy of the record into a memory on a portable customer secure mediumthereby providing the retail customer with a verifiable copy of theretail transaction record.
 3. The method of claim 2 wherein the portablecustomer secure medium is a smart card that a retail customer insertsinto a smart card reader/writer, and further comprising the step of:writing a copy of the record into a memory of a customer's smart cardthereby providing the retail customer with a verifiable copy of theretail transaction record.
 4. The method of claim 2 wherein the portablecustomer secure medium stores additional records, the method furthercomprising the steps of: reading the records; determining which of therecords represents reimbursable business expenses; and transmitting therecords associated with the reimbursable business expenses to anaccounting system.
 5. The method of claim 1 further comprising the stepof appending a retail customer's signature in association with therecord.
 6. The method of claim 5 wherein the portable customer securemedium is a smart card that a retail customer inserts into a merchant'ssmart card reader/writer, and further comprising the step of: writing acopy of the record into a memory of a customer's smart card therebyproviding the retail customer with a verifiable copy of the retailtransaction record.
 7. A method for creating authenticated electronicretail transaction receipts by generating a retail merchant'signature,the method comprising the steps of: storing data in a computer memory,said data comprising a retail merchant identification number, a retailcustomer identification number, and transaction data; generating atransaction specific session key; encrypting said data with thetransaction specific session key to generate a merchant signature;generating a record comprising said merchant signature and detailedtransaction data; and storing the record on a point of sale (POS)system.
 8. The method of claim 7 further comprising the step of writinga copy of the record into a memory on a portable customer secure mediumthereby providing the retail customer with a verifiable copy of theretail transaction record.
 9. The method of claim 8 wherein the portablecustomer secure medium is a smart card that a retail customer insertsinto a smart card reader/writer, and further comprising the step of:writing a copy of the record into a memory of a customer's smart cardthereby providing the retail customer with a verifiable copy of theretail transaction record.
 10. The method of claim 7 further comprisingthe steps of appending a retail customer's signature in association withthe record.
 11. A method for processing a returned retail purchasecomprising the steps of: reading retail transaction data from a memoryof customer secure medium, said retail transaction data including aretail merchant identification number and a retail customeridentification number; reading a merchant signature associated with saidretail transaction data from the memory of the customer secure medium;reading a merchant signature key from a merchant secure medium;encrypting said retail transaction data with the merchant signature keyto generate a generated merchant signature; and comparing said merchantsignature read from a customer secure medium to said generated merchantsignature to the authenticity of said retail transaction data.
 12. Themethod of claim 11 wherein the customer secure medium is a smart cardthat a retail customer inserts into a smart card reader/writer.
 13. Themethod of claim 12 wherein the merchant secure medium is a smart cardthat a retail merchant inserts into a smart card reader/writer.
 14. Themethod of claim 12 wherein the merchant secure medium is a recordpermanently stored in a memory of a merchant POS system.
 15. A systemfor generating and storing verifiable electronic retail transactionreceipts comprising: a point of sale (POS) system including a pluralityof POS terminals, said terminals comprising a microprocessor, a memory,an operator keyboard, an operator display, a cash drawer; a storecontroller; a computer program executed by the POS system for storingdata in the memory comprising a retail merchant identification number, aretail customer identification number, and transaction data, saidprogram for encrypting said data with a merchant supplied signature keyto generate a merchant signature and generating a verifiable electronicretail transaction receipt comprising said merchant signature anddetailed transaction data; and a customer secure medium and a merchantsecure medium for storing said verifiable electronic retail transactionreceipts.
 16. The system of claim 15 wherein the POS system furthercomprises a smart card reader/writer and wherein the customer securemedium is a smart card that a retail customer inserts into said smartcard reader/writer.
 17. The system of claim 15 wherein the POS systemfurther comprises a smart card reader/writer and wherein the merchantsecure medium is a smart card that a retail merchant inserts into saidsmart card reader/writer.
 18. A method for creating authenticatedelectronic retail transaction receipts by generating a retail merchant'ssignature, the method comprising the steps of: storing data in acomputer memory, said data comprising a retail record having at leastone element related to a transaction; storing in a computer memory amerchant supplied signature key; encrypting said data with the merchantsupplied signature key to generate a merchant signature; generating arecord comprising said merchant signature and detailed transaction datarelated to the transaction; and storing the record on a point of sale(POS) system.
 19. The method of claim 18 further comprising the step ofwriting a copy of the record into a memory on a portable customer securemedium thereby providing the retail customer with a verifiable copy ofthe retail transaction record.
 20. The method of claim 19 wherein theportable customer secure medium is a smart card that a retail customerinserts into a smart card reader/writer, and further comprising the stepof: writing a copy of the record into a memory of the customer's smartcard thereby providing the retail customer with a verifiable copy of theretail transaction record.
 21. The method of claim 18 further comprisingthe step of appending a retail customer's signature in association withthe record.
 22. The method of claim 21 wherein the portable customersecure medium is a smart card that a retail customer inserts into amerchant's smart card reader/writer, and further comprising the stepsof: writing a copy of the record into a memory of a customer's smartcard thereby providing the retail customer with a verifiable copy of theretail transaction record.